With the spread of the Internet, various electronic businesses are highlighted. To enable computerization of a transaction in particular, the standardization of an EDI protocol in which send and receive methods and data formats of transaction information are defined and the preparation of an industrial infrastructure for performing an electronic transaction using the EDI protocol are advancing. Further, to improve the efficiency of various operations, the preparation of an in-house business system for creating, accumulating, and managing in-house resources, such as business data and documents, in a centralized manner is also advancing. Moreover, resources, such as transaction data and transaction documents, used in the electronic transaction are frequently created, accumulated and managed by this in-house business system. For example, there are a merchandise control system that manages merchandise data and customer data which become the objects of a commercial transaction, a material system that manages received order and ordering data, and a document management system for managing transaction documents, such as a bill and a bill of lading (B/L) for trade.
Further, Japanese Unexamined Patent Publication No. 2000-29672 describes a method for performing the delivery management of software that is not related to an electronic transaction. In the art of the publication, which version of which module of the software to be distributed was distributed is managed as a history every distribution, and the history is used later to redistribute the software.
In such background as this, the demand for the seamless linkage of an EDI system for performing an electronic transaction with an in-house business system has increased. For example, in the in-house business system, the efficiency in the data and document interchange between the in-house business system and the EDI system can be improved by fetching the data necessary for the electronic transaction from the business data managed in a centralized manner, automatically creating input data into the EDI system, attaching an accumulated transaction document to EDI data, and automatically accumulating a transaction document sent from a customer in the in-house business system.
FIG. 14 shows an example when a document management system and an EDI system are linked. The document management system of FIG. 14 prepares and updates a transaction document, such as a bill or a bill of lading (B/L). Further, the EDI system creates EDI data including a transaction No. (transaction number), a sender, a receiver, and a sending date. On this occasion, the transaction document prepared by the document management system is selected and attached to the EDI data. The EDI system sends the EDI data to which the transaction document was attached to a customer or receives the EDI data from the customer.
As described above, when the in-house business system and the EDI system are linked, a history indicating when which transaction data and transaction document of the in-house business system were actually interchanged with a customer as the EDI data needs to be able to be managed, a transaction be advanced continuously, and the history be referred to when a trouble occurred. However, when the document management system and the EDI system are linked, simply leaving the history indicating which transaction document was interchanged with the customer as the EDI data by such method as Japanese Unexamined Patent Publication No. 2000-29672 will cause the following problems (1), (2), (3) and (4).
(1) A transaction document is prepared and updated by multiple persons in an enterprise, and the same document is frequently used for a transaction multiple times. FIG. 15 shows the example. In FIG. 15, a person in charge A prepares a bill and a bill of lading (B/L), and a person in charge B modifies the bill of lading (B/L). Subsequently, the person in charge B attaches the bill and the modified bill of lading (B/L) to EDI data and sends the EDI data. Further, the person in charge A remodifies the bill and the bill of lading (B/L) and attaches them to the EDI data, then resends the EDI data. The preparation and modification operations of the transaction document and the EDI transaction operations are performed complicatedly in this manner. Accordingly, to efficiently advance these operations, the preparation history of the transaction document, that is, the version information of the transaction document and the transaction history of the EDI data need to be able to be managed in a centralized manner and referred to easily.
(2) The EDI system negotiates transaction contents by repetitively interchanging EDI data with a customer and establishes a transaction in the end. Accordingly, a transaction document prepared by the customer may be attached to the received EDI data or the customer may modify and return the sent transaction document. FIG. 16 shows one of the examples. In FIG. 16, the company B modifies the transaction document sent from the company A to the company B and returns it to the company A. The company A remodifies the transaction document that the company B modified and resends it. Accordingly, a document management system needs also to be able to update the received transaction document. However, as described in Japanese Unexamined Patent Publication No. 2000-29672, such receiving information as described above cannot be managed and reused using an art that controls a version of software only at the distribution side one-sidedly and manages only a distribution history.
(3) The EDI system may fail in EDI data sending or disable the sending, such as a transaction is canceled, due to a time limit after the EDI data is sent. Even when such sending is disabled, it is not known that the sending was disabled only by managing the distribution history like the art described in Japanese Unexamined Patent Publication No. 2000-29672.
(4) In the case of the EDI system, a customer updates a sent document and returns it. Accordingly, if a transaction document is freely modified in an enterprise while a response from the customer is being awaited after the transaction document is sent, a double update will occur, and consistency of the transaction document will not be achieved. That is, it will be unknown that the document of which version is to be updated next or the document of which version is to be sent when the document is resent.
In view of these problems, Issues of the present invention are as follows: (a) A preparation history of a transaction document and a transaction history of EDI data to which this preparation history was attached can be associated and managed. (b) An interchange history of the transaction document with a customer can be managed with consistency. (c) The efficiency of the preparation operations of the transaction document and the transaction operations of the EDI data can be improved. (d) Operations histories can be referred to easily.
An object of the present invention is to provide an art that can solve these issues.